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Abstract 

This  report  describes  a  method  to  discriminate  different  ISO/MPEG  1 
Audio  Layer-3  (MP3)  encoding  programs  by  statistical  characteristics  of 
the  compressed  audio  files.  Encoders  are  classified  according  to  10  statisti¬ 
cal  features  by  a  Naive  Bayes  Classifier ,  which  can  be  induced  from  a  set  of 
test  data.  A  classification  experiment  led  to  a  success  rate  of  96  %  correct 
classifications.  The  authors  discuss  all  features  and  refer  to  possible  lim¬ 
itations  of  feature  selection.  In  addition,  empirical  evidence  showed  that 
a  pre-classification  of  MP3  encoders  increases  the  reliability  of  detection 
methods  for  steganographic  content.  The  proposed  scheme  reduced  the 
error  rate  of  an  attack  against  mp3stego  from  about  75%  false  positives 
to  15%  misses.  Implications  for  the  generalisability  to  other  file  formats, 
and  contributions  for  related  applications  are  also  addressed. 


Keywords:  Steganalysis,  MP3  Encoder  Classification,  Digital  Forensics 


*This  project  was  supported  by  the  Air  Force  Office  of  Scientific  Research  under  the  re¬ 
search  grant  number  FA8655-03-1-3A46.  The  U.  S.  Government  is  authorised  to  reproduce  and 
distribute  reprints  for  Governmental  purposes  notwithstanding  any  copyright  notation  there 
on.  The  views  and  conclusions  contained  herein  are  those  of  the  authors  and  should  not  be 
interpreted  as  necessarily  representing  the  official  policies,  either  expressed  or  implied,  of  the 
Air  Force  Office  of  Scientific  Research,  or  the  U.  S.  Government. 


CONTENTS 


2 


Contents 

11  Introduction! 


2  Analysis  of  MP3  Specification 

2.1  Principles  of  MP3  Compression  .  . 

2.2  Level  of  Analysis  and  Related  Work 

2.3  Scope  and  Terminology] . 

13  Procedurel 

3.1  Set-up  of  Test  Database . 

3.2  Tool  Development . 


4  Description  of  Features 

4.1  Calculation  of  Size  Control  Quantities  . 

4.1.1  Feature  1 

Effective  Bit  Rate  Ratio! . 

4.1.2  Feature  2 

Granule  Size  Balance| . 

4.1.3  Feature  3 

Reservoir  Usage  Ramp| . 

4.1.4  Feature  4 

Entropy  of  Big  Values . 

14.2  Model  Decisionl 


4.2.1 

Feature  5: 

Preflag  Ratio . 

4.2.2 

Feature  6: 

Block  Type  Transitions 

4.3 

Oanabilitv  Tlsave 

4.3.1 

Feature  7: 

SCFSl  Usage . 

4.3.2 

Feature  8: 

Frame  Length  Alignment  . 

14.3.3 

Feature  9: 

Huffman  Table  Selection! . 

14.4  Miscellaneous! 


4.4.1  Feature  10:  Stuffing  Byte  Values 

4.4.2  Concluding  Rcmarks| . 


5 

Experimental  Results 

5.1  Validity  for  Known  Data  .  .  . 

5.2  Reliability  for  Unknown  Data] 

5.3  Application  for  Steganalysis|  . 

16  Discussion  and  Conclusion! 


16.1  Limitations  and  Future  Directions! 


6.2  Transferability  to  Other  Compression  Formats 

6.3  Related  Applications 

A  Appendix| 

A.l  Supplementary  Tables 

A. 2  Sample  Session|  .  .  .  . 

5 

7 

7 

8 

10 

12 

12 

14 

16 

16 

16 

17 

18 

18 

20 

20 

21 

22 

22 

22 

22 

23 

23 

23 

24 

24 

25 

26 

28 

28 

29 

29 

32 

32 

36 


LIST  OF  FIGURES 


3 


List  of  Figures 


1  Structure  of  MP3  file  as  R  object 


15 


2  Relation  between  effective  bit  rate  and  file  length  for  selected  en¬ 


coders! 


3 

Comparison  of  size  control  in  stereo  files 

4 

Valid  MP3  block  type  transitions 

5 

Comparison  of  average  classification  confidence 

17 

19 

21 

26 


List  of  Tables 


1 

Structure  of  ISO/MPEG  1  Audio  Layer-3  encoding  process 

....  8 

2 

Share  of  bit  rates  of  MP3  filcsl . 

....  13 

3 

A-posteriori  probabilities  for  frequently  identified  encoders 

....  27 

4 

Overview  of  features  used  for  classification! . 

....  32 

5 

List  of  Analysed  MP3  Encoders . 

....  33 

6 

Classifier  performance  on  training  data  (S  =  T) . 

....  34 

7 

Classifier  performance  on  disjoint  test  data  (S  fl  T  =  0)  .  . 

....  35 

LIST  OF  TABLES 


4 


List  of  Abbreviations 


ACM 

API 

CBR 

CD 

CHAMP3 

CRC 

DSP 

FFT 

FLD 

GUI 

ID3 

IIS 

IJG 

ISO 

JPEG 

JSP 

kbps 

LGPL 

LSB 

MB 

MDCT 

MP3 

MPEG 

NBC 

PCM 

SCFSI 

SCMS 

SQAM 

SVM 

VBR 


1.  Audio  Compression  Manager 

2.  Association  for  Computing  Machinery 
Application  Programming  Interface 
Constant  Bit  Rate 

Compact  Disc 

Statistical  Characterisation  of  MP3  Encoders  (Project  title) 

Cyclic  Redundancy  Check 

Digital  Signal  Processing 

Fast  Fourier  Transformation 

Fisher  Linear  Discriminant  Analysis 

Graphical  User  Interface 

Identifier  for  MP3  hies 

(Fraunhofer)  Institut  Integrierte  Schaltungen 

Independent  JPEG  Group 

International  Organization  for  Standardization 

Joint  Photographic  Experts  Group 

Java  Server  Pages 

Kilobits  per  Second 

Lesser  General  Public  License 

Least  Significant  Bit 

Megabyte 

Modified  Discrete  Cosine  Transformation 

ISO/MPEG  1  Audio  Layer-3 

Moving  Picture  Experts  Group 

Naive  Bayes  Classifier 

Pulse  Code  Modulation 

Scale  Factor  Selection  Information 

Serial  Copy  Management  System 

Sound  Quality  Assessment  Material 

Support  Vector  Machine 

Variable  Bit  Rate 


1  INTRODUCTION 


5 


1  Introduction 

The  invention  of  the  ISO/MPEG  1  Audio  Layer-3  (MP3)  audio  compression  al¬ 
gorithm  mm  is  probably  one  of  the  most  remarkable  and  far-reaching  develop¬ 
ments  in  the  area  of  digital  media  processing.  The  MP3  format  enables  compres¬ 
sion  rates  of  about  1/10  of  the  size  of  uncompressed  digital  audio  while  degrading 
the  audible  quality  only  marginally.  Together  with  the  moderate  complexity  of 
the  compression  algorithm — software  implementations  of  MP3  coders/decoders 
(codecs)  with  acceptable  performance  even  on  low  budget  home  computers  soon 
became  available — the  format  simplified  the  interchange  of  music  and  resulted 
in  worldwide  popularity  for  its  users  and  sleepless  nights  for  the  music  industry. 
The  popularity  of  the  format  fostered  demand  for  encoding  tools  and  opened  a 
market  for  a  variety  of  programs  for  different  needs.  Today  we  count  hundreds 
of  MP3  encoder  front-ends  based  on  several  dozens  of  encoding  engines  ranging 
from  proof  of  concept  hacks  to  targeted  products  either  tuned  for  high  speed,  or 
optimised  to  costly  and  flexible  tools  for  professional  studio  requirements. 

Given  these  facts,  the  MP3  format  became  an  interesting  carrier  for  stegano- 
graphically  hidden  data.  Steganography,  which  is  somewhat  linked  with  cryptog¬ 
raphy,  aims  to  conceal  the  very  existence  of  a  confidential  message  by  hiding  it 
imperceptibly  within  other,  less  suspicious  data  EH.  MP3  is  a  promising  carrier 
format  for  steganography  in  three  ways.  At  first,  the  popularity  of  the  format  is 
an  advantage,  because  exchanging  common  and  widely  used  types  of  data  is  less 
conspicuous  to  an  observer.  For  example,  sharing  an  MP3  hie  over  the  Internet 
is  a  completely  common  task  and  doing  so  is  a  plausible  form  of  communica¬ 
tion.  Second,  MP3  hies  are  typically  between  2  and  4  megabytes  (MB)  in  size 
and  thus  are  larger  than  other  commonly  used  formats  (e.g.,  text  documents 
or  photographs  as  e-mail  attachments).  All  forms  of  information  hiding  suffer 
from  a  small  proportion  of  payload  compared  to  the  total  amount  of  informa¬ 
tion,  which  is  necessary  to  cover  the  message.  So,  larger  hie  sizes  simplify  the 
handling  of  medium-sized  payloads  (e.g.,  a  text  message  or  a  photograph).  The 
inconveniences  that  come  with  splitting  up  messages  over  different  carriers  can 
be  almost  avoided  for  MP3  hies.  Third,  the  nature  of  the  lossy  MP3  compression 
itself  makes  it  attractive  for  steganographic  use.  The  information  loss  that  is  a 
concomitant  of  the  encoding  process  creates  a  certain  amount  of  unpredictability 
that  can  be  exploited  to  carry  hidden  information  securely. 

Compared  to  the  suitability  of  MP3  hies  for  steganography,  the  amount  of 
known  steganographic  tools  for  this  format  is  still  quite  limited.  MP3Stego  [22] 
is  based  on  the  8hz-mp3  encoder  [1]  and  hides  message  bits  in  the  parity  of  block 
length.  Although  this  procedure  is  limited  to  a  very  low  capacity,  it  is  (under 
certain  conditions,  see  below)  detectable  [2E] .  The  attack  is  based  on  the  analysis 
of  statistical  properties,  i.e.,  the  variance  of  block  lengths  in  the  MP3  stream. 
Stego-Lame  |23j  pursues  another  approach  and  embeds  into  uncompressed  Pulse 
Code  Modulation  (PCM)  audio  data.  The  amount  of  information  is  so  small 
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and  the  embedding  procedure  so  carefully  selected,  that  a  subsequent  lossy  MP3 
compression  does  not  erase  the  hidden  information.  This  tool  is  still  in  an  experi¬ 
mental  stage.  An  appropriate  attack  is  delivered  in  the  same  bundle.  In  addition 
to  these  publicly  known  stego-tools  we  expect  some  more  being  used  in  the  wild. 
Although  the  complexity  of  MP3  compression  exceeds  those  of  typical  stegano- 
graphic  tools  (e.  g.,  LSB  image  embedding),  the  availability  of  commented  source 
codes  for  MP3  encoders  facilitates  the  composition  of  derivates  with  stegano- 
graphic  extensions.  Hence,  advances  in  the  detection  of  steganographic  data  in 
MP3  hies  are  relevant. 

The  experience  with  the  existing  attack  against  MP3Stego  shows  that  the 
detection  procedure  can  distinguish  MP3  hies  with  and  without  steganographic 
content  quite  reliably  if  they  are  encoded  with  either  MP3Stego  or  its  underlying 
encoding  engine  [Tj.  However,  hies  from  other  encoders  tend  to  have  similar  sta¬ 
tistical  properties  as  steganograms  from  MP3Stego  and  thus  are  identihed  as  false 
positives.  Hence,  the  reliability  of  the  detection  algorithm  heavily  depends  on 
the  prior  knowledge  about  the  encoder  of  a  particular  hie.  While  this  situation 
might  be  sufficient  for  an  academic  attack  or  proof  of  concept,  it  is  definitely  not 
optimal  for  real  world  applications.  In  the  heldwork,  we  usually  cannot  expect 
any  prior  knowledge  about  the  source  of  an  arbitrary  MP3  hie.  We  therefore 
present  a  procedure  to  determine  the  encoder  of  MP3  hies  on  the  basis  of  sta¬ 
tistical  features  that  are  typical  for  a  certain  implementation  of  the  MP3  format 
specification.  The  insertion  of  a  preclassihcation  of  MP3  encoders  allows  a  stegan- 
alyst  to  run  the  appropriate  detection  algorithm  for  the  determined  encoder  and 
thus  dramatically  decrease  the  amount  of  false  positives.  Thus  it  is  believed  that 
statistical  classification  of  MP3  encoders  can  increase  the  reliability  of  detection 
procedures. 

The  rest  of  this  report  is  organised  as  follows.  In  the  next  section  we  briefly 
review  the  relevant  particularities  of  the  MP3  format  that  are  analysed  for  the 
extraction  of  statistical  features.  Section  [3]  sums  up  the  project  realisation  and 
describes  the  main  steps  to  follow  the  presented  procedures.  The  features  them¬ 
selves  are  explained  in  Section  |4j  Experimental  results  that  back  the  performance 
of  the  proposed  scheme  are  presented  in  Section  [5j  before  we  discuss  further  ap¬ 
plications  and  possible  generalisations  to  other  hie  formats  in  Section  [6j 
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2  Analysis  of  MP3  Specification 

The  purpose  of  this  section  is  not  to  repeat  the  architecture  and  specification  of 
MP3  compression  mm ,  but  to  give  a  brief  overview  of  those  principles  that  are 
relevant  as  features  for  our  proposed  statistical  classification.  Hence,  we  focus  on 
the  latitudes  that  are  left  in  the  ISO  specification,  which  leave  space  for  different 
implementations.  It  is  the  vaguely  defined  particularities  that  finally  lead  to 
different  output  streams  for  the  same  input  data. 

2.1  Principles  of  MP3  Compression 

The  developers  of  MP3  audio  compression  included  several  techniques  to  max¬ 
imise  the  relationship  between  perceived  audio  quality  and  storage  volume.  In 
contrast  to  previous  schemes,  they  designed  a  two-track  approach.  On  the  first 
track,  the  audio  information  is  split  up  into  32  equally  spaced  frequency  sub¬ 
bands.  These  components  are  separately  mapped  into  the  time  domain  with  a 
Modified  Discrete  Cosine  Transformation  (MDCT).  The  following  quantisation 
step  reduces  the  precision  of  the  MDCT  coefficients.  As  a  last  step,  a  lossless  en¬ 
tropy  encoding  of  the  quantised  coefficients  leads  to  the  compact  representation 
of  MP3  audio  data.  The  second  track  is  very  important  for  the  performance  of 
MP3  encoding,  because  it  is  used  as  a  control  track.  Also  starting  from  the  PCM 
input  data,  a  1024-point  Fourier  transformation  is  used  to  fit  the  local  frequency 
spectrum  as  input  to  a  psycho-acoustic  model.  This  model  emulates  the  particu¬ 
larities  of  human  auditory  perception  and  derives  appropriate  masking  functions 
for  the  input  signal.  The  model  is  used  to  control  the  choice  of  block  types  and 
quantisation  factors  in  the  first  track.  Hence,  this  two-track  approach  adaptively 
finds  an  optimal  trade-off  between  data  reduction  and  audible  degradation  for  a 
given  input  signal. 

Regarding  the  underlying  data  format,  an  MP3  stream  consists  of  a  series  of 
frames.  Synchronisation  tags  separate  frames  from  other  information  sharing  the 
same  transmission  or  storage  stream  (e.  g.,  video  frames).  For  a  given  bit  rate,  all 
MP3  frames  have  a  fixed  compressed  size  and  represent  a  fixed  amount  of  1152 
PCM  samples.  Usually,  an  MP3  frame  contains  32  bits  of  header  information,  an 
optional  16  bit  Cyclic  Redundancy  Check  (CRC)  checksum,  and  two  granules  of 
compressed  audio  data.  Each  granule  can  be  subdivided  into  one  (mono)  or  two 
(stereo)  blocks.  Since  the  actual  block  size  depends  on  the  amount  of  information 
that  is  required  to  describe  the  input  signal,  it  may  vary  between  frames.  To 
match  the  floating  block  sizes  with  the  fixed  frame  sizes  without  wasting  band¬ 
width,  the  MP3  standard  introduces  a  so-called  reservoir  mechanism.  Frames 
that  do  not  use  their  full  capacity  are  filled  up  (partly)  with  block  data  of  sub¬ 
sequent  frames.  This  method  assures  that  local  highly  dynamic  sections  in  the 
input  stream  can  be  stored  with  over-average  precision,  while  less  demanding 
sections  allocate  under-average  space.  However,  the  extent  of  reservoir  usage  is 
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limited  in  order  to  decrease  the  interdependencies  between  more  distant  frames 
and  to  facilitate  resynchronisation  in  the  middle  of  a  stream. 

2.2  Level  of  Analysis  and  Related  Work 

In  order  to  perform  a  statistical  characterisation  of  MP3  encoders  we  have  to 
find  differences  in  the  encoding  process.  These  differences  may  have  multiple 
causes.  At  the  first  glance,  all  loosely  defined  parameters  in  the  specification  are 
subject  to  different  interpretations.  However,  the  standard  precisely  describes  a 
large  set  of  critical  parameters  including  the  exact  coefficients  for  the  filter  bank 
and  threshold  values  for  the  psycho-acoustic  model.  Nevertheless,  some  imple¬ 
mentations  seem  to  vary  or  fine  tune  these  parameters.  In  addition,  performance 
evaluations  may  have  led  to  sloppy  implementations  of  the  standard,  such  as 
shortcuts  in  the  inner  quantisation  loop  or  the  choice  of  non-optimal  Huffman 
tables.  Also,  a  number  of  parameter  defaults  for  meta  information  are  up  to 
the  implementor  (e.  g.,  the  Serial  Copy  Management  System  (SCMS)  flags,  also 
known  as  protection  bit  HU)-  All  these  variations  together  cause  particular  fea¬ 
tures  in  the  output  stream  that  are  indications  of  a  specific  encoder  and  therefore 
are  subject  to  a  detailed  analysis. 


Table  1:  Structure  of  ISO/MPEG  1  Audio  Layer-3  encoding  process 


Transformation  Layer 

Modelling  Layer 

Bit  Stream  Layer 

Functionality 

-  Filter  bank 

-  Quantisation  loop 

-  Auxiliary  data 

-  MDCT  transform 

-  Model  decisions 

-  Frame  header  bits 

-  FFT  transform 

-  Table  selection 

-  Checksums 

-  Stream  formatting 

Points  for  analysis 

-  Frequency  range 

-  Size  control 

-  Surface  information 

-  Filter  noise 

-  Model  decisions 

-  SCMS  protection  bit 

-  Audible  artefacts 

-  Capability  usage 

-  SCMS  original  bit 

To  structure  the  occurrences  of  implementation  specific  particularities  in  the 
MP3  encoding  process,  we  will  subdivide  the  process  into  three  layers  as  shown  in 
Table  [lj  The  transformation  layer  includes  all  “passive”  operations  that  directly 
affect  the  audio  data,  namely  the  filter  bank,  and  the  MDCT  and  Fast  Fourier 
(FFT)  time  to  frequency  transformations,  respectively.  In  this  layer,  variations 
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in  the  filter  coefficients  or  in  the  precision  of  the  floating  point  operations  may 
cause  measurable  features  such  as  typical  frequency  ranges  or  additional  noise 
components. 

We  define  all  “active”  components  of  the  compression  algorithm  as  part  of 
the  modelling  layer.  These  sub-processes  are  less  close  to  the  underlying  audio 
data  and  mainly  perform  the  trade-off  between  size  and  quality  of  the  compressed 
data.  In  this  layer,  encoder  differences  basically  occur  in  three  ways: 

1.  Calculation  of  size  control  quantities,  e.g.,  whether  net  or  gross  hie  sizes 
are  used  as  reference  for  the  bit  rate  control. 

2.  Model  decisions:  Different  threshold  values  lead  to  different  marginal  dis¬ 
tributions  of  control  parameters  over  the  data  stream. 

3.  Capability  usage:  Some  encoders  do  not  support  all  compression  modes 
specified  in  the  MP3  standard. 

The  uppermost  layer,  which  we  call  bit  stream  layer ,  handles  the  formatting  of 
already  compressed  MP3  frames  into  a  valid  bit  stream.  These  operations  include 
the  composition  of  frame  headers,  the  optional  calculation  of  CRC  checksums  for 
error  detection,  and  the  insertion  of  meta  data.  For  instance,  quasi-standardised 
ID3  tags  [E]  contain  information  about  the  names  of  artists,  interprets,  and  pub¬ 
lishers  of  audio  hies.  Optional  VBR  ( variable  bit  rate )  headers  store  additional 
data  evaluated  by  some  MP3  players  to  display  valid  progress  bars  and  enable 
efficient  skipping  within  MP3  hies  with  variable  bit  rate]]]  The  existence  of  a 
certain  kind  of  meta  information  and  its  default  values  may  be  used  as  indicator 
for  the  encoding  program. 

EncSpot  [5],  the  only  tool  for  MP3  encoder  detection  we  know,  relies  on  the 
deterministic  surface  parameters  of  the  bit  stream  layer.  As  these  parameters  are 
easily  accessible,  it  is  also  simple  to  erase  or  change  their  values  and  therefore 
trick  this  kind  of  encoder  detection.  Therefore  we  decided  to  use  statistical  fea¬ 
tures  related  with  deeper  structures  of  the  encoder  and  thus  are  more  difficult 
to  manipulate.  Our  initial  experiments  with  parameters  of  the  transformation 
layer  showed  that  those  tend  to  be  dependent  on  the  type  of  audio  data  actually 
encoded.  For  example,  it  is  impossible  to  measure  encoder  characteristics,  such 
as  the  upper  frequency  bound,  if  the  encoded  audio  material  does  not  use  the  full 
range.  Also,  artefacts  occur  at  typical  envelopes  or  frequency  changes  that  do 
not  appear  similarly  in  all  kinds  of  music.  Hence,  we  decided  to  focus  our  level 
of  analysis  to  the  modelling  layer,  which  promises  to  deliver  the  most  robust 
features  in  terms  of  source  data  independency  and  difficulty  of  manipulation. 

1As  MP3  has  been  specified  for  constant  bit  rates  (CBR)  the  majority  of  MP3  files  are 
encoded  as  CBR  with  one  of  the  predefined  rates.  However,  some  encoding  programs  optionally 
encode  each  frame  with  a  different  bit  rate  (out  of  the  predefines  rates),  thus  enabling  variable 
bit  rate  (VBR)  streams  with  MP3. 


2  ANALYSIS  OF  MP3  SPECIFICATION 


10 


2.3  Scope  and  Terminology 

To  precisely  describe  the  nature  of  used  features  we  introduce  some  formal  no¬ 
tations.  We  denote  a  medium  m  as  m0  for  the  source  (i.e.,  uncompressed)  rep¬ 
resentation  and  as  m*  =  efimo)  if  it  is  encoded  with  encoding  program  et  is 
element  of  the  set  of  n  encoders  E  =  {ei,e2,  •  ■  ■ ,  en}.  We  write  the  set  of  all  hies 
encoded  using  e*  as  M*  =  e*(M0),  where  M0  is  the  set  of  all  uncompressed  source 
media. 

The  function  f(m)  extracts  a  symbolic  feature  x  from  m.  The  vector  of  k 
different  features 


x  =  f(m)  =  (/i(m),  f2(m), . . . ,  fk{m)) 

is  called  feature  vector.  The  components  of  the  feature  vector  x  are  selected  to  be 
as  similar  as  possible  for  different  media  m  G  Mi  encoded  with  the  same  encoder 
ei,  and  also  as  dissimilar  as  possible  for  all  encoded  media  m  G  {ej(m0)\j  i} 
that  are  derived  from  m 0  by  encoding  it  with  other  encoders.  Therefore  the 
information  about  the  characteristics  of  the  encoding  program  is  consolidated  in 
the  value  of  x. 

Classifiers  are  algorithms  which  automatically  classify  an  object,  i.e.,  assign 
it  according  to  its  features  to  one  of  several  predefined  classes.  As  the  litera¬ 
ture  contains  multiple  options,  the  choice  of  a  specific  algorithm  for  our  purpose 
was  determined  by  the  conditions  given  in  our  application.  Fisher  Linear  Dis¬ 
criminant  (FLD)  methods  and  Support  Vector  Machines  (SVM)  have  already 
been  successfully  applied  for  steganalysis  mm-  These  methods  perform  well  for 
numeric  (i.e.,  continuous)  features,  but  are  less  suitable  for  symbolic  features. 
Hence,  we  chose  to  apply  a  classifier  which  is  based  on  Bayesian  logic  [17].  As 
we  will  show  in  Section  [5j  we  get  notable  results  with  the  simple  Naive  Bayes 
Classifier  (NBC)  00 

We  use  a  classifier  c  to  establish  the  relation  between  a  specific  instantiation  of 
x  =  f(m*)  and  the  encoding  program  e;  that  was  used  to  create  m*.  If  we  do  not 
have  any  knowledge  about  the  encoder,  we  can  only  derive  probabilistic  evidence 
about  this  assignment.  For  a  given  medium  m  a  classifier  tries  to  compute  the 
conditional  probabilities 


P(ej|f(m))  =  P{a \x!  =  fi(m),x2  =  /2H,  ...,xk  =  fk{m)), 


with  1  <  i  <  n,  and  then  selects  the  most  probable  encoder  ej,  so  that 
P(e;|f(m))  >  P(ei|f(m)),  V  ej  G  P\{ei},  i  =  c(f(m)). 

2These  results  are  coherent  with  the  findings  from  a  comprehensive  evaluation  of  different 
classifiers:  Compared  to  a  set  of  complex  classification  models,  the  simple  NBC  performed 
equal  or  superior  for  many  realistic  decision  problems  [16] . 
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The  classifier’s  performance  depends  on  its  parameterisation,  which  can  be 
induced  from  data.  Therefore  we  assemble  a  training  set 

T  =  {(*,  ej(m))|l  <  i  <  n  A  m  e  M0}. 

Each  element  of  T  contains  a  compressed  representation  of  medium  m  and  a 
reference  to  the  known  encoding  program.  We  note  a  classifier  trained  with  the 
training  set  T  as  ct-  The  encoder  prediction  of  a  specific  instantiation  of  x,  and  of 
an  underlying  medium  m  will  be  denoted  as  ct(x)  and  cr(f(ui)),  respectively.  To 
evaluate  the  quality  of  the  classification,  we  regard  the  proportion  p  of  correctly 
classified  cases  when  the  classifier  is  run  on  elements  of  a  test  set  S,  which  is 
composed  similarly  to  the  training  set  T : 

,  C\  l{(*>m<)  e  S\l  =  c(f(m*))}l 

p(c’s)  = - |S| - 

As  a  weak  form  of  reliability  evaluation,  the  same  training  set  T  can  be 
reclassified,  thus  cr(f(mj))  with  {ipm.j)  e  T.  A  somewhat  stronger  measure  can 
be  achieved  for  disjoint  test  and  training  sets,  so  that  S  fl  T  =  0. 
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3  Procedure 


The  CHAMP3  Project  was  accomplished  between  June  2003  and  March  2004 
at  Technische  Universitat  Dresden,  Germany.  It  has  been  organised  into  three 
main  tasks.  First,  we  accomplished  preparatory  tasks  such  as  the  development  of 


analytical  tools  for  MP3  hies  (cf.  Section  3.2)  and  the  set-up  of  a  test  database  of 
MP3  hies  from  different  encoders.  The  encoder  selection  process  and  the  obstacles 
we  faced  are  described  in  Section  3T  Second,  analytical  research  was  conducted 
to  find  distinguishing  features  between  different  encoders.  This  task  is  difficult 
to  describe  because  of  its  iterative  and  explorative  nature.  It  was  mainly  driven 
by  systematic  comparisons  of  the  most  promising  parameters  of  MP3  hies.  The 
third  task  included  further  tests,  the  implementation  of  a  prototype,  and  hnal 
documentation.  The  resulting  sources  and  binaries  are  attached  to  this  report 
and  a  brief  tutorial  of  how  to  use  the  provided  software  is  given  in  Appendix  |A.2| 


3.1  Set-up  of  Test  Database 

To  arrange  a  training  set  for  our  experiments,  we  had  to  collect  the  most  im¬ 
portant  MP3  encoders.  The  search  was  oriented  to  well-known  names,  such  as 
Fraunhofer  or  Xing,  as  well  as  to  general  advices  from  bulletin  boards  on  the 
Internet.  To  complete  our  collection,  we  used  the  hie  names  of  archives  as  search 
terms  in  Google  to  get  references  to  similar  content,  which  turned  out  to  contain 
further  encoders. 

We  installed  and  examined  several  dozen  MP3  encoders;  however,  we  realised 
that  most  of  them  rely  on  the  same  back-end  and  simply  differ  in  their  user 
interfaces.  The  back-ends  we  found  are  mainly  13enc  by  Fraunhofer,  lame,  and 
bladeenc.  While  bladeenc  and  13enc  essentially  appeared  in  one  version,  lame 
came  in  several  builds  from  varying  compilers  and  with  different  hie  names. 

Some  MP3  encoders  provide  the  user  with  a  large  number  of  adjustable  pa¬ 
rameters.  For  instance,  lame  leaves  dozens  of  independent  choices  for  noise 
shaping,  psycho-acoustic  algorithms,  hlters,  and  bit  rate  (constant,  average,  and 
variable),  thus  offering  several  thousand  possible  combinations.  Moreover,  open- 
source  tools  in  particular  are  frequently  updated  and  new  releases  can  have  very 
minor  changes.  Since  there  are  hardly  any  parameters  supported  by  all  MP3 
encoders,  we  created  the  MP3  hies  for  our  database  using  the  respective  default 
parameters.  The  bit  rate  is  the  only  parameter  we  varied.  We  used  the  bit  rates 
112  kbps,  128  kbps,  and  192  kbps,  which  we  believe  to  be  the  most  commonly 
used  ones.  We  back  this  assumption  with  evidence  from  an  online  user  survey 
at  http :  //www .  mp3- tech .  org/,  and  by  counting  several  collections  of  MP3  hies. 
The  results  are  documented  in  Table  [2]  With  some  exceptions  (I3enc,  mp3comp, 
shine),  the  selected  rates  are  supported  by  all  other  encoders. 

The  ideal  audio  content  for  our  database  would  be  a  representative  selection 
of  music,  either  drawn  from  the  set  of  commercially  available  recordings  or  sam- 
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Table  2 

:  Share  of  bit  rates  of 

MP3  hies 

Bit  rate 

Estimated  proportion 

Poll  on  MP3tech.org 

MP3  collections 

(February  2003) 

(about  20  K  hies) 

320  kbps 

8.0% 

0.2% 

224-256  kbps 

7.2% 

0.4% 

160-192  kbps 

27.0  % 

12.9% 

128  kbps 

22.6  % 

69.5% 

112  kbps 

1.0% 

4.9% 

64-96  kbps 

3.0% 

9.3% 

up  to  56  kbps 

7.1% 

2.4% 

other 

24.1% 

0.4% 

100  % 

100  % 

pled  from  Peer-to-Peer  (P2P)  file  sharing  systems.  However,  we  tried  to  find  a 
compromise  between  an  extensive  database  and  a  limited  set-up  time.  So  we  had 
to  limit  the  search  in  some  respects  according  to  our  resources.  For  instance,  we 
did  not  examine  any  hardware  MP3  encoder. 

It  is  desirable  to  have  an  automated  set-up  process  for  the  database  so  that 
additional  audio  sources,  encoders,  or  encoder  settings  can  later  be  added  with 
minor  effort.  This  is  a  challenging  task,  because  the  encoders  run  on  different 
platforms  (Linux,  DOS,  MacOS,  and  Windows).  For  the  test  database,  most 
encoders  were  called  from  shell  scripts  under  Linux.  A  large  part  of  the  Windows 
and  DOS  software  even  runs  under  Linux  with  emulation  software,  such  as  wine 
[27]  and  dosemu  [3].  To  assure  that  these  rather  atypical  application  environments 
do  not  influence  the  resulting  MP3  hies,  we  compared  the  binary  hies  with  those 
from  native  platforms.  Nonetheless,  the  remaining  tools  not  working  with  one 
of  the  available  emulations  had  to  be  run  manually  on  the  respective  original 
platforms. 

Windows  encoders  use  so-called  Audio  Compression  Manager  (ACM)  mod¬ 
ules.  These  ACM  libraries  are  stored  in  the  Windows  system  directory.  If  Win¬ 
dows  encoders  use  different  ACM  modules  with  identical  hie  names,  they  mutu¬ 
ally  overwrite  each  other.  Be  aware  that  an  encoder  installed  under  Windows 
sometimes  produces  MP3  hies  with  different  properties  after  another  encoder  has 
been  installed.  Hence,  it  is  advisable  to  install  each  encoder  in  its  own  Windows 
installation  (e.g.,  under  VMware  |j25]).  Furthermore,  many  Windows  encoders  we 
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found  on  the  Internet  are  silently  bundled  with  spyware]^] 

3.2  Tool  Development 

The  R  Project  for  Statistical  Computing  |23l  H2]  is  a  powerful  language  for  data 
analysis  and  graphics,  which  comes  with  a  wide  variety  of  specific  statistical  func¬ 
tions.  As  it  is  released  as  free  and  open  source  software,  it  is  highly  extensible. 
We  chose  this  technology  as  environment  for  the  analytical  parts  of  CHAMP3. 
However,  we  had  to  develop  additional  import  functions  to  access  statistical  fea¬ 
tures  of  MP3  hies  directly.  Our  implementation  of  the  interface  library  is  based  on 
mpglib  [9],  which  is  released  under  the  Lesser  General  Public  License  (LGPL) 
[6].  The  new  function  load. mp3  returns  an  mp3info  structure  representing  a 
given  input  MP3  hie. 

According  to  the  prior  explanation  of  the  MP3  hie  format  structure,  we  de¬ 
signed  a  data  structure  to  map  MP3  hies  into  R  objects.  It  is  a  convention  that  R 
functions  store  complex  data  structures  in  so-called  list  objects.  The  members 
of  a  list  are  accessible  either  by  name — like  associative  arrays — or  by  number. 
The  mp3  inf  o  structure  contains  up  to  four  nested  lists,  one  for  each  data  parsing 
level: 


•  global:  a  list  of  hie  specihc  information 

•  frames:  a  data  frame  object  holding  the  header  parameters  for  each  frame 

•  blocks:  a  data  frame  object  holding  information  for  every  block;  for  stereo 
hies,  two  adjacent  entries  represent  one  granule 

•  coeff:  a  data  frame  object  holding  the  576  quantised  MDCT  coefficients 
for  each  block 

The  exact  structure  of  the  mp3info  object,  including  all  relevant  attributes, 
is  depicted  in  Figure  [l]  As  the  R  representation  of  MP3  objects  allocates  a 
multiple  of  the  hie  length  of  an  MP3  hie  in  memory,  the  load. mp3  function  is 
highly  conhgurable.  This  enables  the  user  to  extract  only  the  information  which 
he  or  she  actually  needs  for  a  certain  analytical  task.  For  example,  since  none  of 
the  features  we  use  for  the  classihcation  requires  the  exact  coefficient  values  (as 
already  mentioned,  we  do  not  use  characteristics  of  the  transformation  layer),  we 
do  not  need  to  import  the  coefficient  data  at  all. 


3Spyware,  sometimes  called  spybots  or  tracking  software,  is  a  technology  to  secretly  gather 
information  about  the  user  and  relay  it  to  advertisers  or  other  interested  parties. 
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MP3  Object 


global 


frame 


block 


coe 


-  filename 

-  length 

-  id3. length 

-  aid. length 


length 

size 

header 

bitrate 

freq 

-  sterec^j 

-  jsbound 

-  single 

-  Ifs 

-  mpeg25 

-  header. change 

-  layer 

-  crc 

-  bitrate. index 

-  freq. index 

-  padding 

-  ext 

-  mode 

-  mode. ext 

-  copyright 

-  original 

-  emphasis 


-  part23. length 

-  big. values 

-  countl. values 

-  stereo 

-  gain.O 

-  gain.l 
-gain. 2 

-  gain.pow2 

-  table. 0 

-  table. 1 

-  table. 2 

-  region.  1 

-  region. 2 

-  block. type 

-  mixed. flag 

-  compress. scale 

-  scale 


-  mdct:l 

-  mdct:2 

-  mdct:3 


-  mdct:575 

-  mdct:576 


Figure  1:  Structure  of  MP3  file  as  R  object 

“load. mp3 ()  returns  the  following  flags  only  if  expand. flags=TRUE  is  specified. 
foThe  coeff  data  frame  is  only  included  if  the  parameter  coeff  is  explicitly  set. 


4  DESCRIPTION  OF  FEATURES 


16 


4  Description  of  Features 

As  a  result  of  iterative  comparisons  and  analyses  of  MP3  encoder  differences,  we 
discovered  a  set  of  10  features  in  the  modelling  layer.  For  a  structured  presenta¬ 
tion,  the  features  are  assigned  to  categories,  which  will  be  discussed  separately 
in  the  following  subsections. 


4.1  Calculation  of  Size  Control  Quantities 

Distinct  encoders  seem  to  differ  in  the  way  the  target  bit  rate  is  calculated,  as 
we  discovered  measurable  differences  in  the  effective  bit  rate.  According  to  the 
MP3  standard,  each  block  can  be  encoded  with  one  of  14  predefined  bit  ratesj^] 
However,  because  of  the  difficulty  to  reach  an  exact  compressed  size,  these  act  just 
as  guiding  numbers.  Some  encoders  treat  these  rates  as  an  upper  limit,  others  as 
an  average.  Also,  the  encoders  differ  in  the  scope  of  frames  that  are  evaluated  as 
control  parameters  for  the  compression  loop.  If  broader  scopes  are  used,  or  fixed 
headers  at  the  beginning  of  MP3  hies  are  also  reflected  in  the  quantisation  loop, 
then  the  effective  bit  rate  varies  with  the  hie  length  and  converges  to  a  target 
value  with  an  increasing  number  of  frames. 


4.1.1  Feature  1:  Effective  Bit  Rate  Ratio 

These  phenomena  are  depicted  in  Figure  [2]  for  four  selected  encoders  on  the  basis 
of  hies  with  a  nominal  bit  rate  of  128  kbps.  The  curves  are  drawn  according 
to  a  least  square  estimate  with  a  linear  and  a  hyperbolic  term  over  measured 
data  points]^]  The  effective  bit  rates  /3eg  of  8hz-mp3  and  mp3comp  depend  on  the 
number  of  frames  r,  while  there  is  no  influence  for  hies  encoded  with  lame  or 
fhgprod.  We  calculate  the  effective  bit  rate  as 


PeE 


[(hlesize)  —  (junkbytes)  —  (met a  information)]  •  8  •  <p 

1152 -r 


with  ip  =  44.1kHz  as  sampling  frequency.  Even  for  large  hies  we  observe  a 
measurable  difference  in  the  marginal  /3eg  between  all  four  encoders.  To  derive  a 
bit  rate  independent  feature  from  this  observation,  we  calculate  a  criteria  Q\  as 
ratio  between  the  effective  bit  rate  (3eg  and  the  nominal  bit  rate  /3nom : 


Qi  = 


with  /?nom 


1 

r 


r 


y  qO 

/  j  /^noi 


where  Yom  is  the  nominal  bit  rate  given  in  the  header  of  the  i-th  frame.  To  map 

4Bit  rates  for  Layer-3  in  kbps:  32,  40,  48,  56,  64,  80,  96,  112,  128,  160,  192,  224,  256,  320 
5R2  values  range  between  0.83  and  0.97. 


4  DESCRIPTION  OF  FEATURES 


17 


Effective  Bit  Rate 


Figure  2:  Relation  between  effective  bit  rate  and  file  length  for  selected  encoders 


this  ratio  to  a  symbolic  feature  we  define  the  extraction  function  f\  as  follows: 


xi  =  fi{m) 


0  for  o,  <  1-1- 10“4 

1  for  1  -  1  •  10-4  <  Qi  <  1 

2  for  1  <  Qi  <  1  +  5  •  10~6 

3  else. 


The  number  of  levels  and  the  exact  boundaries  for  this  feature,  as  well  as 
for  the  following  ones,  are  determined  by  an  iterative  process  of  comparing  a  set 
of  test  audio  hies.  We  report  the  functions  which  lead  to  the  best  experimental 
results,  even  though  further  optimisation  is  still  possible. 


4.1.2  Feature  2:  Granule  Size  Balance 

In  Section |2T ,  we  mentioned  that  an  MP3  stream  consists  of  a  sequence  of  frames. 
Again,  two  granules  share  a  frame  of  fixed  size.  The  quantisation  loop  adjusts 
the  size  of  the  granules  separately  according  to  two  criteria: 
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1.  Size:  The  granule  must  fit  into  the  available  space. 

2.  Quality:  Signal  noise  shall  remain  imperceptible. 


For  some  encoders,  e.  g.,  shine,  we  observed  a  slight  bias  for  quality  over  size. 
As  the  ‘hard’  space  limit  counts  on  both  granules  together,  the  first  granules 
of  all  frames  (1  <  i  <  r )  tend  to  get  bigger  than  the  second  ones  g% \  ffence,  we 
measure  the  proportion  of  frames  in  the  hie  where  the  length  of  the  first  granule 
len(<7i)  dominates  the  second  one  1011(5(2): 

p2  =  -J2G(i),  with 
r  ^ 


r(r]  _  f  1  for  lcn(^c))  >  len^) 
U[X)  “  \  0  else. 


Again,  we  dehne  a  mapping  function,  now  for  feature  X2- 


h(m)  = 


0 

for 

Q2 

< 

0.50 

1 

for 

0.50 

< 

Q2 

< 

0.55 

2 

3 

for 

else. 

0.55 

< 

Q2 

< 

0.70 

4.1.3  Feature  3:  Reservoir  Usage  Ramp 

The  next  feature  makes  use  of  characteristics  of  the  reservoir  mechanism.  We 
found  that  the  abruptness  of  the  rise  in  reservoir  usage  between  silent  and  dy¬ 
namic  parts  in  the  audio  stream  differs  between  some  encoders.  Other  encoders 
even  do  not  use  the  reservoir  at  all.  As  the  vast  majority  of  audio  hies  start  with 
a  tiny  silence,  we  derive  the  feature  X3  from  the  amount  of  bytes  shared  between 
the  hrst  and  the  second  frame  i>(i,2): 


/sM 


0  for  V(iti+ 1)  =  0  V  i:  1  <  i  <  r 

1  for  v{i,2)  >  300 

2  else. 


The  function  f 3(1x1)  is  zero  if  the  reservoir  is  not  used  in  the  whole  hie.  The  values 
1  and  2  identify  hard  and  soft  reservoir  usage,  respectively. 


4.1.4  Feature  4:  Entropy  of  Big  Values 

The  last  feature  in  this  category  is  less  theoretically  based  and  our  evaluations 
show  that  it  has  little  impact  on  the  classification  result,  except  for  a  better 
separation  between  two  versions  of  the  Xing  encoder,  namely  xing98  and  xing3. 
However,  we  report  it  for  the  sake  of  completeness.  We  observed  that  xing3  uses 
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Channel  2:  Number  of  big  MDCT  coefficients 
(Histogram  over  frames  of  a  typical  1 28  kbps  file) 


Figure  3:  Comparison  of  size  control  in  stereo  files  encoded  with  xing3  and 
xing98 


a  different  size  control  mechanism  for  the  second  block  of  every  granule  of  stereo 
hies.  The  differences  are  clearly  visible  in  the  histogram  of  lengths  of  big  value 
MDCT  coefficients  (see  Figure  [3]).  Following  the  ISO/MPEG  1  Audio  Layer-3 
terminology  [13],  big  values  are  the  partition  of  spectral  coefficients  with  absolute 
values  greater  than  1.  This  partition  holds  the  most  energy  of  the  transformed 
audio  signal  and  thus  the  average  number  of  big  values  is  a  valid  indicator  for  the 
extent  of  size  reduction  in  the  quantisation  loop.  To  derive  a  continuous  feature 
from  the  different  spread  of  histogram  values  in  the  stereo  channel,  we  measure 
the  entropy  from  the  histogram  with  the  approximation  given  in  [|T9]: 

^max 

H  ps  —  ^2  dj  log  dj  +  log  Ax, 

3= 1 

with  dj  denoting  the  density  of  occurrences  in  the  j'-th  bin  and  Ax  as  bin  size. 
Since  Ax  is  constant  for  all  encoders,  we  use  a  simplified  function  to  calculate 
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feature  £4 : 

60 

AN  =  -^djlogdj 

i=i 

Note  that  in  contrast  to  previous  features,  f'flrn)  is  a  continuous  feature  that  is 
modelled  by  the  classifier  as  a  normal  distributed  random  variable  with  mean 
/i-4-1  and  standard  deviation  cq-4-  for  the  f-th  encoder  e%.  However,  as  this  feature 
evaluates  the  characteristics  of  the  second  channel  in  stereo  data,  it  is  not  ap¬ 
plicable  to  mono  hies;  hence,  we  cannot  discriminate  between  xing3  and  xing98 
for  mono  hies. 

4.2  Model  Decision 

The  psycho-acoustic  model  is  a  second  source  for  distinguishing  features.  Differ¬ 
ences  in  the  computation  of  control  parameters  or  modifications  in  the  choice  of 
threshold  values  lead  to  typical  marginal  distributions  of  measurable  parameters. 

4.2.1  Feature  5:  Preflag  Ratio 

The  binary  value  preflag  causes  an  additional  amplification  of  high  frequencies 
and  is  individually  set  for  each  compressed  block  bi  (1  <  i  <  q,  with  q  as  number 
of  blocks  in  a  hie).  Concerning  the  treatment  of  this  parameter,  the  ISO/MPEG  1 
Audio  Layer-3  standard  explicitly  leaves  latitude: 

“The  condition  to  switch  on  the  preemphasis  is  up  to  the  imple¬ 
mentation.  ”  [HI  P.  no] 

To  derive  an  operable  feature  we  calculate  the  proportion  of  blocks  with  preflag 
set 


1  q 

Qb  =  -  ^2  preflag(fcj) 

and  map  it  into  disjoint  regions  for  the  symbolic  feature  £5|^] 


'  0 

for 

Qb 

= 

0.00 

1 

for 

0.00 

< 

Qb 

< 

0.01 

2 

for 

0.01 

< 

Qb 

< 

0.05 

3 

for 

0.05 

< 

Qb 

< 

0.10 

4 

for 

0.10 

< 

Qb 

< 

0.21 

5 

for 

0.21 

< 

Qb 

< 

0.35 

6 

for 

0.35 

< 

Qb 

< 

0.62 

7 

for 

0.62 

< 

Qb 

< 

0.77 

.  8 

else. 

6Our  experiments  show  that  the  symbolic  interpretation  of  £5  leads  to  better  classification 
results  than  a  treatment  as  continuous  feature  with  assumed  normal  distribution. 
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4.2.2  Feature  6:  Block  Type  Transitions 

The  MP3  audio  format  offers  different  block  types,  which  allow  an  optimal  trade¬ 
off  for  sections  requiring  higher  time  resolution  at  the  cost  of  frequency  resolution 
and  vice  versa.  The  majority  of  blocks  are  encoded  with  block  type  0,  the  long 
block  with  lower  time  and  higher  frequency  resolution.  Block  type  2  defines  a 
short  block ,  which  offers  less  coefficients  to  be  stored  for  three  different  points 
in  time.  Two  more  block  types  are  specified  to  perform  smooth  shifts  between 
the  above  mentioned  types.  Hence,  the  standard  defines  a  graph  of  valid  block 
transitions  between  two  adjacent  blocks  bi  and  bl+y,  as  shown  in  Figure  |4j 


Figure  4:  Valid  MP3  block  type  transitions 

An  evaluation  of  block  type  transitions  of  MP3  files  from  different  encoders 
uncovers  two  interesting  details:  First,  some  encoders  (shine,  all  xing*)  do  not 
use  short  blocks  at  all  and  thus  always  encode  with  block  type  0.  Second,  other 
encoders  (lame,  gogo,  and  plugger)  include  specific  “illegal”  transitions,  mainly 
at  the  beginning  of  a  file.  As  these  transitions  are  rarely  observable  from  other 
encoders,  they  identify  the  encoder  reliably.  Hence,  we  construct  the  extraction 
function  for  feature  xe  as  follows]^] 


'  0 

for 

type(6j)  =  0 

V  i:  1  <  i  <  q 

(shine,  xing*) 

1 

for 

type(i>i)  =  0 

A  type(62)  =  2 

(lame) 

f&{m)  =  < 

2 

for 

type(fci)  =  2 

A  type(62)  =  3 

(gogo) 

3 

for 

|{6i|type(6i) 

=  2}|  =  {6j  type(fej)  =  3}|  =  1 

(plugger) 

4 

else. 

We  have  no  other  explication  for  these  strange  transitions  than  assuming  that 
they  are  intended  to  leave  a  kind  of  encoder  fingerprint  in  the  output  data.  It  is 
up  to  a  deeper  analysis  of  these  particularities  in  the  source  code  to  reveal  further 
evidence. 

'For  simplicity  we  give  the  relations  for  mono  files.  Stereo  files  work  similar  if  blocks  are 
evaluated  in  pairs.  The  given  definition  is  not  disjoint,  hence  the  values  are  assigned  by  the 
first  matching  condition. 
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4.3  Capability  Usage 

The  third  category  of  features  exploits  the  fact  that  some  encoders  do  not  im¬ 
plement  all  functions  specified  in  the  MP3  standard.  We  call  this  category  capa¬ 
bility  usage  and  clearly  separate  these  capabilities  from  surface  parameters,  such 
as  header  flags,  because  the  latter  can  easily  be  changed  without  touching  the 
compressed  data. 


4.3.1  Feature  7:  SCFSI  Usage 

The  Scale  Factor  Selection  Information  (SCFSI)  is  a  parameter  that  allows  an 
encoder  to  reuse  scale  factors  for  subsequent  parts  of  the  stream  if  they  do  not 
change  over  time.  However,  this  compression  method  is  only  used  by  few  en¬ 
coders,  namely  lame,  gogo,  and  xingac21  ( “AudioCatalyst” ) .  We  define  a  fea¬ 
ture  X7  which  reflects  the  use  of  SCFSI: 

,.  ,  .  (O  for  scfsi(fej)  =  0  V  i:  1  <  i  <  q 
*(mH  1  else. 


4.3.2  Feature  8:  Frame  Length  Alignment 

Although  MP3  frames  have  a  fixed  length,  the  amount  of  information  used  to 
describe  the  respective  audio  signal  may  vary.  We  refer  to  this  quantity  as  effective 
frame  length  leneff(i).  According  to  the  MP3  standard,  the  effective  frame  length 
has  no  constraints  to  match  a  multiple  of  bytes,  words  or  quad-words.  However, 
we  observed  that  some  encoders  (8hz-mp3,  bladeenc,  m3ec,  plugger,  shine, 
soloh)  adjust  all  effective  frame  lengths  to  byte  boundaries,  while  others  do  not. 
We  use  this  characteristics  as  feature  x8: 


/sM 


0  for  leneff(i)  =  0  mod  8  V  v.  1  <  i  <  r 
1  else. 


4.3.3  Feature  9:  Huffman  Table  Selection 

After  the  quantisation,  the  MDCT  coefficients  are  further  compressed  by  a  Huff¬ 
man  style  entropy  coder.  I11  contrast  to  the  method  proposed  by  Huffman  ra. 
the  tables  are  not  computed  from  the  marginal  symbol  distribution.  In  order  to 
avoid  the  transmission  of  marginal  distributions  or  table  data,  the  developers  of 
MP3  standardised  a  set  of  28  pre-defined  Huffman  tables  that  were  empirically 
optimised  for  the  most  probable  cases  in  audio  compression.  In  the  very  rare  case 
of  longer  code  words  an  escape  mechanism  allows  storage  of  uncompressed  values. 
An  MP3  encoder  chooses  the  most  suitable  table  separately  and  independently 
for  each  of  the  three  regions  of  the  big  value  MDCT  coefficients.  As  there  is  no 
efficient  method  to  perform  an  optimal  table  selection,  some  encoders  increase 
performance  by  using  heuristics  to  quickly  select  a  suitable  table,  rather  than  the 
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optimal  one.  From  a  comparison  of  table  usage  frequencies,  we  found  two  note¬ 
worthy  characteristics:  First,  all  Xing  encoders  seem  to  avoid  strictly  using  table 
number  0  for  region  2 Second,  only  a  few  encoders  (m3ec,  mp3enc31,  uzura) 
use  table  23  for  the  regions  1  and  2.  We  exploit  these  observations  as  additional 
information  for  our  classification: 

for  table2(&i)  7^  1  V  i:  1  <  i  <  q 
for  3 (bi,j):  table,,(&j)  =  23, 

1  <i<q,  j  =  1,2 

else. 

Also,  shine  uses  only  a  subset  of  the  defined  tables.  However,  as  we  can  already 
identify  this  rarely  used  encoder  with  several  other  features,  we  refrain  from 
adjusting  this  feature  for  the  detection  of  shine. 


4.4  Miscellaneous 

4.4.1  Feature  10:  Stuffing  Byte  Values 

Since  our  last  feature  does  not  fit  in  any  of  the  above  categories,  we  decided  to 
explain  it  separately.  Independent  from  whether  the  reservoir  mechanism  is  used 
or  not,  there  may  be  a  couple  of  bytes  unused  and  filled  up  to  meet  the  fixed 
frame  length.  These  so-called  stuffing  bits  can  be  set  to  any  arbitrary  values.  For 
a  closer  examination  of  these  values,  we  composed  histograms  of  the  byte  values 
in  the  stuffing  areas.  While  most  encoders  set  all  stuffing  bits  to  zero,  we  still 
found  some  exceptions  and  mapped  them  into  a  symbolic  feature  Xiq: 


fio{m) 


0  for  stuffing  with  zeros 

1  for  no  stuffing  at  all 

<  2  for  stuffing  with  0x55  or  Oxaa 

3  for  stuffing  with  “G0G0”  (0x47  and  0x4f ) 

4  else. 


4.4.2  Concluding  Remarks 

The  enumeration  of  features  in  this  section  is  a  subset  of  particularities  we  took 
into  account  and  from  which  we  selected  the  most  promising  ones.  The  selection 
is  far  comprehensive,  so  it  is  still  feasible  to  find  further  differentiating  features. 
Such  features  may  be  necessary  to  reliably  separate  new  encoders,  or  encoders 
that  were  not  included  in  our  initial  analysis. 


8According  to  the  standard,  we  count  the  regions  from  zero. 
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5  Experimental  Results 

For  our  experimental  work,  we  used  the  R  Statistical  Framework  [T21  [231]  and 
implemented  an  extension  for  statistical  analyses  of  MP3  files  on  the  basis  of  the 
open  source  MP3  player  mpg!23  [9J.  All  results  are  based  on  an  MP3  database  of 
about  2,400  files  encoded  with  20  different  encoders  (cf.  Table  [5]  in  the  Appendix 
A.l).  The  audio  data  was  selected  from  different  sources  to  make  the  measure¬ 


ments  independent  from  specific  types  of  music  or  speech.  We  included  tracks 
from  a  re-mastered  CD  of  Grammy  Nominees,  from  a  compilation  of  Blues  Broth¬ 
ers  (including  some  live  recordings),  further  piano  music  by  Chopin,  as  well  as 
Sound  Quality  Assessment  Material  (SQAM)  files  with  speech  and  instrumental 
sounds.  All  source  files  were  read  from  CD  recordings  and  stored  as  PCM  wave 
files  with  44.1kHz,  16  bit,  stereo. 

If  provided,  we  encoded  every  source  audio  with  three  constant  bit  rates 
that  we  believe  are  the  most  widely  used  rates  for  MP3  hies,  namely  112  kbps, 
128  kbps,  and  192  kbps.  Additional  MP3  hies  with  variable  bit  rates,  with  two 
quality  settings  each,  were  generated  by  the  encoders  iTunes,  lame,  and  xingac21. 


5.1  Validity  for  Known  Data 

To  measure  the  performance  of  our  proposed  method,  we  implemented  a  Naive 
Bayes  Classiher  (NBC)  [4j  for  hxed  feature  vectors  of  both  symbolic  and  con¬ 
tinuous  features.  In  the  hrst  experiment,  we  trained  the  classiher  Ctx  with  a 
training  set  Ti  of  about  2,400  cases.  For  each  case,  we  extract  a  feature  vector 
f  (mi)  from  a  hie  encoded  with  a  defined  encoder  e*  and  use  these  tuples  to  induce 
classification  parameters  for  cr,  •  To  evaluate  the  performance  of  cr,  we  use  the 
same  feature  vectors,  because  Si  —  7j ,  as  input  to  the  classiher  and  compare  the 
predicted  encoders  to  the  known  true  values.  The  results  are  shown  in  Table  [6]  in 
the  Appendix  A.l  In  this  experiment  we  reach  a  hit  rate  of  pi^c^,  TQ  =  96.2%. 
As  a  measure  of  confidence,  we  calculate  the  average  a-posteriori  probability  over 
the  predicted  encoders  Pmax  =  96.1%.  The  classiher  calculates  the  a-posteriori 
probability  max*  P(ej|f(m))  for  each  hie  on  the  basis  of  the  feature  vector. 

Table  [4]  summarises  the  features  proposed  in  Section  |4j  We  use  a  jack-knife 
method  to  empirically  evaluate  the  importance  of  each  feature  for  the  classifica¬ 
tion  result.  Therefore  the  training  and  classification  procedure  is  repeated  several 
times,  while  excluding  individual  features  one  by  one.  The  resulting  increase  of 
misses  in  the  classification  table  is  a  measure  for  the  importance  of  a  feature. 
According  to  these  values,  the  effective  bit  rate  seems  to  be  the  most  important 
feature,  followed  by  the  method  of  reservoir  usage. 

A  closer  look  at  the  results  shows  that  the  main  sources  for  classification  er¬ 
rors  occur  between  tightly  related  encoding  engines,  such  as  the  DOS  and  UNIX 
versions  of  Fraunhofer’s  13enc,  and  between  two  subsequent  versions  of  Xing  en¬ 
coders  (xing3  and  xing99).  Also,  soloh  produces  false  classifications  as  8hz-mp3, 
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especially  for  source  files  from  the  Blues  Brothers  CD.  To  explore  these  misclassi- 
fications,  we  debugged  the  soloh  binary  and  found  references  to  an  early  version 
of  the  8hz-mp3  encoder.  Hence,  the  similarity  in  statistical  features  may  reveal 
insights  about  the  “intellectual  origin”  of  certain  encoders. 

To  support  our  results  and  reduce  the  risk  of  tautological  finding,  we  repeat 
the  experiment  with  a  split-half  method.  We  trained  the  classifier  ct2  with  a 
sub  sample  T2  of  the  first  training  set  7\.  All  other  elements  from  Xf  are  used 
in  the  test  set  S2,  so  that  T2  fl  S2  =  0.  The  results  of  this  second  experiment 
are  shown  in  Table  [7]  (in  the  Appendix  A.l).  We  found  an  overall  hit  rate  of 
p(ct2,S2 )  =  94.9%  and  an  average  a-posteriori  probability  of  95.9%.  As  both 
quality  measures  differ  only  marginally  from  the  first  experiment  (—1.3  and  —0.2 
percentage  points,  respectively),  we  conclude  that  the  proposed  method  can  also 
reliably  identify  the  encoders  of  unknown  MP3  hies. 


5.2  Reliability  for  Unknown  Data 

We  used  classifier  crx  to  determine  the  encoders  of  a  random  sample  of  3,000 
MP3  hies  drawn  from  different  sources,  for  a  total  amount  of  more  than  19,000 
MP3  hies.  The  overall  average  a-posteriori  probability  is  86.9  %.  This  is  about  10 
percentage  points  below  the  values  for  known  data.  We  still  consider  this  a  good 
value  because  we  are  aware  that  our  training  set  certainly  does  not  include  all 
available  encoders.  In  addition,  some  well  separable  encoders  in  our  assembled 
test  database,  such  as  uzura  and  shine,  have  not  been  identified  in  the  mass  of 
unknown  hies. 

Figure  [5]  shows  the  distribution  of  a-posteriori  probabilities  for  known  and 
unkown  test  dataj^]  The  average  a-posteriori  probability  for  the  most  frequent 
encoders  is  shown  separately  in  Table  [3j 

Encoders  e*  not  included  in  the  training  procedure  may  lead  to  misclassihca- 
tions  in  either  of  two  ways:  If  the  feature  vector  f(m*)  is  similar  to  one  of  the 
trained  encoders  then  we  face  a  misclassihcation  without  noticing  it.  In  this  case, 
the  classiher  reports  a  high  a-posteriori  probability,  also  interpreted  as  confidence 
measure,  and  the  known  features  are  “blind”  towards  the  differences  between  the 
two  encoders.  To  overcome  this  problem,  one  has  to  search  for  new  features  be¬ 
tween  the  existing  and  the  new  encoders.  In  the  second  case,  the  feature  vector 
f(m*)  is  dissimilar  from  the  typical  values  of  the  trained  encoders.  In  this  case, 
the  classiher  reports  a  low  a-posteriori  probability  signifying  the  difficulties  in  as¬ 
signing  the  actual  feature  vector  to  one  of  the  trained  classes.  This  case  is  more 
favourable  because  the  classification  problem  is  identified.  The  new  encoder  can 
be  added  to  the  classiher  by  retraining  its  parameters  with  an  extended  set. 


9The  latter  has  been  reduced  to  bit  rates  between  112  kbps  and  192  kbps,  keeping  2912  files. 
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Known  Test  Data 


Unknown  Test  Data 
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Figure  5:  Comparison  of  classification  confidence  between  self  generated  test  data 
(left)  and  data  collected  in  the  wild  (right). 

5.3  Application  for  Steganalysis 

To  demonstrate  the  advances  in  steganalysis  due  to  preclassification,  we  assem¬ 
bled  a  test  set  of  about  500  pristine  MP3  hies  from  different  encoders  together 
with  369  steganograms  from  MP3stego  [22] .  If  we  run  the  attack  against  MP3stego 
[2Bj  directly  on  the  test  set,  we  clearly  identify  all  369  steganograms  but  face 
an  additional  377  false  positives  (75.4%).  Using  the  proposed  method  as  pre- 
classifier  to  filter  all  hies  from  other  encoders  but  8hz-mp3  removes  all  false 
alarms,  while  still  312  steganograms  are  reliably  detected.  The  miss  rate  of 
15  %  can  further  be  reduced  by  using  a  specially  trained  classiher  for  this  pur¬ 
pose.  Only  in  combination  with  source  classihcation  does  the  detection  method 
have  sufficient  discriminative  power  to  be  suitable  for  a  large  scale  search  for 
steganograms  in  MP3  hies. 
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Tabic  3:  A-posteriori  probabilities  for  frequently  identified  encoders 


Confidence  Pmax(e 

x) 

Rank 

Encoder 

Share 

L 

cr 

n 

1. 

fhgprod 

17.3% 

0.87 

0.14 

381 

2. 

xingac21 

11.6% 

0.99 

0.04 

256 

3. 

13enc272 

10.7% 

0.95 

0.08 

235 

4. 

sound jam 

10.0% 

0.97 

0.11 

220 

5. 

bladeenc 

9.0% 

0.83 

0.16 

198 

6. 

mp3 comp 

8.8% 

0.88 

0.16 

193 

7. 

lame  a 

8.6% 

0.56 

0.11 

190 

“The  low  confidence  may  be  due  to  different  versions  of  lame;  our  training  data  has  been 
encoded  with  the  recent  V  3.93. 
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6  Discussion  and  Conclusion 

In  this  report,  a  method  is  presented  to  determine  the  encoder  of  ISO/MPEG  1 
Audio  Layer-3  data  on  the  basis  of  statistical  features  extracted  from  the  data. 
We  explained  a  set  of  10  features  that  were  used  with  a  Naive  Bayes  Classifier 
to  discriminate  between  20  different  MP3  encoders.  The  results  show,  that  the 
proposed  method  is  quite  reliable  for  special  purpose  test  data  as  well  as  for  a 
sample  of  arbitrary  MP3  hies.  However,  the  proposed  scheme  is  far  from  being 
the  ultimate  solution  and  it  needs  further  refinement  for  real  world  applications. 

6.1  Limitations  and  Future  Directions 

The  first  obstacle  is  the  relatively  narrow  range  of  supported  bit  rates.  In  order 
to  keep  the  test  database  operable,  we  decided  to  concentrate  on  the  most  widely 
used  bit  rates.  Moreover,  we  tried  to  keep  the  features  independent  from  the 
bit  rate.  This  approach  appears  to  have  been  effective,  as  we  do  not  have  any 
problems  when  classifying  variable  bit  rate  (VBR)  hies  despite  never  explicitly 
designing  a  feature  for  VBR  data.  However,  as  some  encoders  change  the  stereo 
model  for  different  bit  rates — especially  for  more  extreme  settings — further  anal¬ 
yses  of  the  robustness  of  the  features  against  bit  rate  changes  may  increase  the 
reliability  of  the  classification. 

As  already  stated,  MP3  hies  support  different  stereo  modes  and  most  encoders 
offer  a  variety  of  options  to  fine  tune  the  encoding  result.  Since  the  test  database 
always  uses  the  (most  likely)  default  settings  and  the  presented  features  do  not 
care  about  other  encoding  modes,  sophisticated  encoding  parameters  may  cause 
false  classihcations.  Hence,  the  influence  of  stereo  modes  and  other  encoding 
options  is  subject  to  further  research. 

In  addition,  some  of  the  present  features  rely  on  hie  parameters  (e.g.,  total 
hie  size)  or  precisely  evaluate  the  beginning  of  a  track  (e.g.,  the  initial  silence). 
These  features  will  fail  if  only  fragments  of  a  stream  shall  be  classihed. 

Regarding  the  composition  of  encoders  in  the  training  set,  we  mainly  cover 
open  source  encoders  and  the  most  widely  used  encoders  from  Fraunhofer  and 
Xing.  The  versions  we  researched  were  not  systematically  selected.  Even  if  we 
are  quite  confident  that  additional  software  encoders  can  be  added  with  moder¬ 
ate  effort,  we  still  have  not  examined  the  characteristics  of  hardware  encoders 
which,  for  example,  are  used  in  portable  digital  audio  recorders.  The  typical 
optimisations  that  are  necessary  to  implement  the  MP3  encoding  algorithm  in 
DSP  hardware  might  cause  features  of  a  different  kind  than  those  we  exploit  to 
differentiate  software  encoders. 

To  complete  the  list  of  open  research  questions,  we  refer  to  possible  interac¬ 
tions  between  statistical  features  used  for  source  classification  and  audio  water¬ 
marking  algorithms. 
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6.2  Transferability  to  Other  Compression  Formats 

The  results  on  MP3  files  show  that  encoder  detection  is  feasible  and  has  useful 
applications  for  steganalysis  and  related  areas.  Hence,  it  might  be  an  interesting 
question  as  to  whether  the  approach  can  be  generalised — certainly  with  adapted 
features — to  other  data  formats. 

Obviously,  the  MP3  format  is  a  good  candidate  for  encoder  detection  for  two 
reasons:  First,  the  popularity  of  the  format,  and  thus  the  demand  for  encoders, 
developed  a  market  for  a  couple  of  parallel  developments  in  the  late  1990s.  Sec¬ 
ond,  the  inclusion  of  a  psycho-acoustic  model  simplifies  the  task  of  feature  discov¬ 
ery,  because  it  leverages  small  numerical  differences  in  the  signal  decomposition 
to  measurable  statistics,  such  as  block  type  frequencies.  From  this  point  of  view, 
MPEG  2  audio  or  MPEG  4  video  seem  to  be  promising  formats  for  similar  re¬ 
search.  Other  formats,  for  example  the  popular  JPEG  image  compression  scheme, 
might  be  quite  harder  to  classify.  This  format  is  less  complicated — at  least  in 
the  way  it  is  used  in  the  overwhelming  majority  of  cases — and  the  Independent 
JPEG  Group  (IJG)  offers  a  standard  implementation  that  is  included  in  many 
applications  [IB]. 

However,  judging  from  our  experience  with  MP3,  we  are  confident  that  similar 
methods  can  be  constructed  for  most  complex  standards  that  leave  latitude  for 
implementations.  Assuming  that  latitude  increases  with  complexity,  we  can  even 
be  quite  optimistic  for  future  formats.  Some  discoveries  we  made,  for  example 
the  block  type  signature  of  open  source  encoders,  back  our  optimism:  As  long 
as  programmers  leave  identifying  traces  by  even  violating  the  standards,  whether 
unintentional  or  motivated  for  one’s  ego,  classification  will  be  feasible.  Neverthe¬ 
less,  it  is  likely  to  always  remain  as  an  iterative  analytical  task,  which  is  difficult 
to  automate. 

6.3  Related  Applications 

Apart  from  the  advances  in  steganalytic  reliability,  the  proposed  method  may 
have  applications  in  two  further  ways.  From  an  academic  point  of  view,  the  in¬ 
sights  gained  from  the  analysis  of  inter-encoder  differences  in  MP3  files  can  be 
used  to  construct  new  steganographic  algorithms.  If  we  know  the  parameters 
that  are  treated  differently  by  different  encoders,  we  can  consider  them  as  inde¬ 
terministic  and  modify  them  to  carry  steganographic  messages.  Also,  the  design 
of  watermarking  algorithms,  which  are  robust  against  MP3  compression,  gains 
from  further  knowledge  about  encoder  differences. 

Last  but  not  least,  a  more  practical  application  for  tools  derived  from  this 
approach  is  digital  forensics.  Knowledge  about  the  encoder  of  a  suspicious  file 
may  lead  to  inferences  about  a  possible  creator.  However,  we  must  note  that  it  is 
still  possible  to  fool  any  of  the  presented  features,  at  least  if  some  effort  is  spent. 
The  output  of  any  of  these  classifiers  is  always  a  probabilistic  guess  and  must  not 
be  considered  as  outright  proof. 
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A  Appendix 

A.l  Supplementary  Tables 


Tabic  4:  Overview  of  features  used  for  classification 


No. 

Description 

Levels 

Importance 

Size  control  features 

X\ 

Effective  bit  rate  ratio 

4 

8.35 

X2 

Granule  size  balance 

4 

0.08 

x3 

Reservoir  usage  ramp 

3 

5.01 

x4 

Entropy  of  big  values 

cont. 

2.15 

Model  decision  features 

x5 

Preflag  ratio 

9 

1.73 

x6 

Block  type  transitions 

5 

1.56 

Capability  usage  features 

x7 

SCFSI  usage 

2 

0.50 

Xs 

Frame  length  alignment 

2 

0.92 

Xg 

Huffman  table  selection 

3 

0.63 

Miscellaneous  features 

XlO 

Stuffing  byte  values 

5 

0.88 

“The  importance  is  measured  with  a  jack-knife  method:  The  column  shows  the  additional 
overall  classification  error  in  percentage  points  if  the  feature  is  left  out.  Hence,  higher  values 
indicate  higher  importance  of  a  feature. 
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Table  5:  List  of  Analysed  MP3  Encoders 


Mnemonic 

Name 

Publisher 

Version 

Year 

8hz-mp3 

8HZ-MP3  Encoder 

8Hz  Productions 

02b 

1998 

bladeenc 

BladeEnc 

Tord  Jansson 

0.94.2 

2001 

f astenc 

FastEnc 

Fraunhofer  IIS 

1.02 

2000 

fhgprod 

Fraunhofer  MP3  Producer 

Opticom 

2.1 

1998 

gogo 

gogo301  petit 

Herurni  and  Pen 

3.01 

2001 

iTunes 

Apple  iTunes 

Apple  Computer  Inc. 

4.1-52 

2003 

13enc272 

13enc  (Linux) 

Fraunhofer  IIS 

2.72 

1997 

13encdos 

13enc  (MS-DOS) 

Fraunhofer  IIS 

2.60 

1996 

lame 

LAME  Ain’t  an  MP3  Encoder 

Mike  Cheng  et  al. 

3.93 

2003 

m3ec 

M3E  Command  Line  Version 

N/A 

0.98b 

2000 

mp3 comp 

MP3  Compressor 

MP3hC 

0.9f 

1997 

mp3enc31 

mp3enc  (Demo) 

Fraunhofer  IIS 

3.1 

1998 

plugger 

Plugger 

Alberto  Demichelis 

0.4 

1998 

shine 

Shine 

Gabriel  Bouvigne 

0.1.4 

2001 

soloh 

SoloH  MPEG  Encoder 

N/A 

0.07a 

1998 

sound jam 

SonndJam  (Macintosh) 

Casady  and  Greene 

2.5.1 

2000 

uzura 

Uzura  3 

N/A  (Fortran  code) 

1.0 

2002 

xing3 

Xing  MP3  Encoder 

Xing  Technology  Corp. 

3.0-32 

1997 

xing98 

Xing  MP3  Encoder  (x3enc) 

Xing  Technology  Corp. 

1.02 

1998 

xingac21 

AudioCatalyst 

Xing  Technology  Corp. 

2.10 

1999 

Note:  All  trademarks  are  the  property  of  their  respective  owners. 


Table  6:  Classifier  performance  on  training  data  (S  =  T) 
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Basis:  \T\  =  |5|  ~  2400  files,  n  =  20  encoders,  k  =  10  features,  overall  error  rate  3.8%,  average  classification  confidence  Pmax  =  0.961 


Table  7:  Classifier  performance  on  disjoint  test  data  (S  fl  T  =  0) 
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Basis:  |T|  =  |Sj  1200  files,  n  =  20  encoders,  k  =  10  features,  overall  error  rate:  5.1%,  average  classification  confidence  Pmax  =  0.959 
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A. 2  Sample  Session 

This  section  shows  how  the  analytical  process  under  R  can  be  handled  and 
presents  an  example  for  encoder  classification.  To  follow  the  session  the  following 
software  is  required: 

1.  R  Statistical  Framework,  free  download  under  http :  //www.r-project .  org 

2.  The  rap3.zip  (Windows  binary)  or  mp3. tar. gz  (Unix  source)  package  de¬ 
veloped  for  CHAMP3 

3.  The  feature  extraction  and  classification  code  (hie  name:  champ3.R) 

4.  A  training  set  of  feature  vectors  (hie  name:  feature .  list  .RData) 

5.  Sample  MP3  hies  from  recommended  encoders 


After  R  is  successfully  set  up,  the  CHAMP3  import  library  has  to  be  installed 
into  the  R  framework.  On  windows,  start  the  R  GUI  environment  and  select 
“ Install  package(s)  from  local  zip  file  ...”  in  the  “ Packages"  menu.  Then  choose 
the  location  of  mp3.zip  and  confirm.  On  Unix  systems,  this  is  accomplished  by 
the  shell  command  line 

bash#  R  CMD  INSTALL  mp3 

where  the  package  mp3. tar. gz  has  to  be  in  the  working  directory.  Note,  that 
super-user  privileges  may  be  required  for  this  step. 

Now  switch  into  the  R  command  line  environment  and  call  the  library  with 

>  library (mp3) 

If  everything  is  loaded  correctly,  you  get  the  following  output: 

MP3  import  library  for  R  (based  on  mpglib) 

(c)  2003-04  Technische  Universitat  Dresden 
URL :  http : //www . inf . tu-dresden.de/ champ3 


The  development  of  this  package  was  supported  by 
the  Air  Force  Office  of  Scientific  Research  under 
the  research  grant  number  FA8655-03-1-3A46 . 


To  load  an  MP3  hie  and  store  it  into  an  R  object  named  m,  type: 

>  m  <-  load. mp3("lame_01 .mp3") 

Start  decoding  ...  decoding  successful. 


A  APPENDIX 


37 


A  help  page  explaining  more  details  of  the  parameters  of  load. mp3  is  available 
by 

>  ?load.mp3 

To  display  the  structure  of  the  MP3  object,  just  enter 


>  m 
List 


of  6 


$  filename 

chr 

"lame_01 .mp3" 

$  length 

int 

-1 

$  id3 . length 

int 

0 

$  aid. length 

int 

0 

$  junk. bytes 

int 

0 

$  stuff. hist 

int 

[1:255]  247  1  1  1  1  1  0  1 

0  0.. 

data. frame ’ : 

10268  obs.  of  8  variables: 

$  length 

int 

288  288  288  288  288  288 

288  288 

288 

288  ... 

$  size 

int 

417  417  418  418  418  418 

418  418 

418 

418  ... 

$  header 

int 

-290716  -290716  -290236 

-290236 

-290236  -290236 

$  bitrate 

int 

128  128  128  128  128  128 

128  128 

128 

128  ... 

$  freq 

int 

44100  44100  44100  44100 

44100  44100 

44100  44100 

$  junk. bytes 

int 

0000000000  ... 

$  backstep 

int 

0  0  381  511  511  511  511 

511  511 

511 

$  error 

logi 

FALSE  FALSE  FALSE  FALSE  FALSE  FALSE  FALSE  . . . 

‘data. frame ; 


41072  obs .  of  20  variables: 


$  frame. parent 

int 

1 

1 

1 

1 

2  2  2  2  3  3 

$  scfsi 

int 

- 

L 

-1 

0 

0-1-100 

-1-1  ... 

$  part23 . length 

int 

0 

0 

0 

0 

0  0  0  0  0  0 

$  big. values 

int 

0 

0 

0 

0 

0  0  0  0  0  0 

$  stereo 

int 

0 

1 

0 

3 

0  5  0  7  0  9 

$  gain.O 

num 

1 

1 

NA 

1  1  1  1  1  1 

$  gain . 1 

num 

1 

1 

1 

1 

111111 

$  gain. 2 

num 

1 

1 

1 

1 

111111 

$  gain.pow2 

num 

1 

lie- 

-16  l.lle-16  1. 

lle-16  l.lle-16  7.07e-01 

$  table. 0 

int 

0 

0 

0 

0 

0  0  0  0  0  0 

$  table . 1 

int 

0 

0 

0 

0 

0  0  0  0  0  0 

$  table. 2 

int 

0 

0 

0 

0 

0  0  0  0  0  0 

$  table. count 1 

int 

0 

0 

0 

0 

0  0  0  0  0  0 

$  region. 1 

int 

2 

2 

2 

2 

18  18  18  18 

2  2... 

$  region. 2 

int 

4 

4 

4 

4 

288  288  288 

288  4  4  ... 

$  block. type 

int 

0 

0 

0 

0 

2  2  3  3  0  0 

$  mixed. flag 

int 

0 

0 

0 

0 

0  0  0  0  0  0 

$  compress . scale 

int 

0 

0 

0 

0 

0  0  0  0  0  0 

$  scale 

int 

0 

0 

0 

0 

0  0  0  0  0  0 
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$  preflag  :  int  0000000000  ... 

Single  elements  of  this  structure  can  be  accessed  by  name.  For  example,  to 
calculate  the  mean  effective  frame  length  in  bits,  enter 

>  mean(m$frames$length) 

[1]  3317.785 

Obviously,  the  whole  set  of  statistical  functions  in  R  can  easily  be  applied  to  MP3 
data.  To  extract  a  feature  vector,  first  load  the  CHAMP3  analysis  functions  into 
the  workspace 

>  source ("champ3.R") 

and  then  use  the  features  function  on  m: 


>  features (m) 

ENC 

FI 

F2 

f; 

"unknown" 

"bps_low" 

"gran_bias_3" 

"back_soft 

F4 

F5 

F6 

F' 

"3.32592000290358" 

"pre_2" 

"block_lame" 

"scf si_yes 

F8 

F9 

F10 

"bit" 

"default" 

"stuff_alt" 

The  way  the  features  are  extracted  and  the  meaning  of  the  symbolic  values  are 
explained  below  in  Section |4}  To  assemble  a  training  set,  one  would  have  to  create 
a  hie  list  as  input  to  the  function  extract .  features.  However,  to  facilitate 
this  time-consuming  step,  we  provide  a  pre-extracted  feature  list  from  our  test 
database.  The  following  command  loads  the  feature  list  into  the  workspace: 

>  load("f eature . list . RData") 

Check  the  structure  of  feature,  list  with  the  function  str: 

>  str (feature . list) 

'data. frame’ :  2371  obs.  of  11  variables: 

$  ENC:  Factor  w/  20  levels  "8hz-mp3" , "blade :  1111111. 
..-  attr(*,  "names" )=  chr  "1"  "2"  "3"  "4"  ... 

$  FI  :  Factor  w/  4  levels  "bps_0" , "bps_l" , . . :  3333333333 
..-  attr(*,  "names" )=  chr  "1"  "2"  "3"  "4"  ... 

$  F2  :  Factor  w /  4  levels  "gran_bias_l" , ..:  2222222222  .. 
..-  attr(*,  "names" )=  chr  "1"  "2"  "3"  "4"  ... 

$  F3  :  Factor  w/  3  levels  "back_hard" , "bac :  33333333 
..-  attr(*,  "names" )=  chr  "1"  "2"  "3"  "4"  ... 

$  F4  :  num  3.53  3.53  3.56  3.63  3.56  ... 

$  F5  :  Factor  w /  9  levels  "pre_l" , "pre_2" , . . :  9899899999 
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attrO,  "names" )=  chr  "1"  "2"  "3"  "4"  ... 

$  F6  :  Factor  w/  5  levels  "block_gogo" , "bl :  55555555  ... 

..-  attrO,  "names" )=  chr  "1"  "2"  "3"  "4"  ... 

$  F7  :  Factor  w/  2  levels  "scf si_no" , "scf s . . " :  1111111111  ... 

..-  attrO,  "names" )=  chr  "1"  "2"  "3"  "4"  ... 

$  F8  :  Factor  w/  2  levels  "bit" , "byte" :  2222222222  ... 

..-  attrO,  "names" )=  chr  "1"  "2"  "3"  "4"  ... 

$  F9  :  Factor  w/  3  levels  "default" , "no-ta. :  1211111112 
..-  attrO,  "names" )=  chr  "1"  "2"  "3"  "4"  ... 

$  F10:  Factor  w/  5  levels  "stuff _alt" , "stu. :  1331133151 
..-  attrO,  "names" )=  chr  "1"  "2"  "3"  "4"  ... 

To  induce  a  classifier  from  the  training  set,  use  the  nbc  ( Naive  Bayes  Classi¬ 
fier)  function.  As  the  part  in  the  command  line  indicates,  the  encoder  index  ENC 
(e*  in  mathematical  notation)  shall  be  predicted  by  all  other  components  of  the 
data  frame  feature .  list. 

classifier  <-  nbc (ENCTF1+F2+F3+F4+F5+F6+F7+F8+F9+F10 , feature . list) 

— or,  much  more  briefly — 

classifier  <-  nbc(ENC~ . ,f eature . list) 

The  function  predict  ,mp3info  (short  cut:  predict)  can  be  used  to  determine 
the  most  probable  encoder  of  m.  To  access  the  first  hit,  type 

>  predict(m,classifier)$ENC[l] 

[1]  "lame" 

Use  predict .  files  to  conveniently  access  the  encoder  classification  for  a  given 
file  name,  or  a  list  of  names.  The  output  of  predict .  files  displays  a  ranking 
of  the  three  most  probable  encoders  together  with  the  respective  a-posteriori 
probabilities. 

>  predict . files ("mp3/lame/grammynom98/audio_01 .mp3" , classifier) 

[1]  "mp3/lame/grammynom98/audio_01 .mp3" 

Start  decoding  ...  decoding  successful, 
rank  ENC  p. value  bitrate 

1  1  lame  1.000000e-00  128 

2  2  gogo  5.162796e-10  128 

3  3  xingac21  1.114803e-12  128 

The  source  code  champ3 .  R  is  also  documented  and  contains  further  hints  on  the 
usage  of  the  provided  commands.  It  also  includes  an  interface  for  a  JSP-based 
web  application  for  MP3  file  analysis,  which  is  online  under  http://www.inf. 
tu-dresden . de/ champ3. 


